In addition, as with many verification projects today, our goals were to develop a high-quality device in an extremely tight time schedule. This article describes our approach to the verification of this complex device and how we addressed the conflicting needs of quality versus complexity versus time.

Excalibur
The Excalibur family of embedded processor programmable logic solutions from Altera provides a combination of processing power, system configurability, and flexibility. The Excalibur physical architecture consists of single and dual port RAM, a 300k-gate standard cell area, an embedded processor IP core, and one-million gates of APEX 20KE PLD all on a single chip, representing some 80 million transistors. The embedded processor core intellectual property (IP) can be an ARM-based embedded processor, a MIPS-based embedded processor, or potentially any merchant embedded processor. To combine the APEX PLD with these externally developed processors, we used an embedded silicon "stripe" and a complex multi-bus architecture. In this context the "stripe" refers to the custom embedded logic area along one edge for the Excalibur die as distinct from the PLD area. The separation is required because of the fundamentally different ways in which the two areas are designed and passed through layout.

The functional architecture consists of four AMBA AHB domains, two within the stripe, and two others providing a standard interface to and from the PLD part of the architecture. A number of peripherals were included in the core architecture in order to provide a complete system on a programmable chip. The EPXA10 device incorporates an ARM922T processor, a full 32-bit ARM9 implementation including memory management, 8k I-cache, 8k D-cache, and an embedded trace module for system debug.

In addition to the processor, the stripe includes:

• A considerable amount of single and dual-port SRAM-up to 256 kbytes of single-port and up to 128 kbytes of dual-port
• An SDRAM controller supporting single data rate (133 MHz) and double data rate (266 MHz) external SDRAMs of up to a total of 512 Mbytes in size.
• Support for external flash, SRAM and memory-mapped peripherals
• A UART
• Configuration logic, programmable memory map and register map
• A number of bridges to decouple the clocks of the various domains.

It was deemed essential that designers and implementers of the PLD IP would not be constrained in their clock choices by the stripe. In order to achieve this, we included bridges between the PLD AHB buses and the stripe internal buses. This will allow the end user to run the processor at maximum frequency without being concerned with any clock synchronization problems between the IP clock and the processor clock. As all this circuitry is built in to the stripe, the user is freed from the onerous task of designing all the necessary clock re-synchronization logic.

Both the ARM and MIPS versions of the processor provide a huge degree of system flexibility. By designing in this type of flexibility, we were able to develop a system that met the opposing requirements of high-end processor performance, complex user IP and complex clocking schemes potentially imposed by such user IP.

While this flexibility is a major plus for the end users of the Excalibur processor, it imposed substantial demands on the design and verification team. Ensuring the high degree of quality that we wanted, conflicted with the massive number of permutations of the system configuration, bus transactions and interactions, plus the integration of IP from a variety of sources and our aggressively short timescales. Our challenges in verifying this system were to simulate a comprehensive range of traffic scenarios from all master sources and to all memory areas, and to provide integrity checks for read/write bursts.

Multi-bus architecture
The Excalibur ARM and MIPS family members contain a minimum of four separate AHB buses, as additional AHB busses can be added to the PLD section. The system was designed with multiple buses in order to meet the opposing requirements of high-performance, integration of several IP cores and complete end user clocking flexibility. By minimizing the number of peripherals on the high-speed bus, we could maximize the clock speed by building a bridge between the two buses and incorporating all the slower peripherals onto the second AHB bus.

The buses are arranged as a three-tier hierarchy. The top two tiers are wholly contained inside the "stripe," while the other two buses are for user IP integration within the programmable part of the system. We made a major design decision early on in the Excalibur development to standardize on the AMBA AHB bus for all four of the buses. For the first device in the Excalibur family, the EPXA10, all of the buses in the embedded ARM device are 32-bits wide (see Figure 1, p. 22).

It was felt that a three-tier bus structure was the only architecture that could support the high target speed for the embedded processor (200 MHz) and key peripherals (SDRAM controller, single-port and dual-port SRAM) and the AHB to AHB bridge. The slower AHB bus contains the address mapping logic, the expansion bus, configuration logic, UART, PLD Master Bridge, and PLD Slave Bridge.

The three aspects of the Excalibur design that made the task of verification more difficult were the multi-bus architecture, the totally configurable address map and clock scheme, and the ÒprogrammableÓ design space offered by the APEX PLD.

The three-tier bus hierarchy introduces considerable complexity in the design and verification of the Excalibur"stripe," not the least of which is the complexity involved in the bridges linking the buses. In addition, a number of the major blocks in the system have two separate asynchronous AHB interfaces. These "dual AHB" modules have internal synchronization and arbitration logic to allow access for the processor and the PLD to key high-performance memories and peripheral functions such as the SDRAM controller.

Verification strategy
As already noted, the verification strategy for the Excalibur had to be fairly sophisticated. The design was very complex and the verification team was tasked with ensuring as high a quality device as possible. Also, the verification team had the requirement that the environment lend itself easily to reuse for future generations, and that engineers who didn't create the environment be able to be productive within it as quickly as possible.

As with any commercial system-on-a-chip development with an aggressive timescale, the minimization of risk is key to delivery. For many commercial developers the decision to adopt a new verification paradigm can seem too risky. Yet for Excalibur verification, we needed a new approach to meet our stringent requirements of a technically advanced solution, reuse and an easy learning curve. We developed the Excalibur verification environment around Verisity's Specman Elite automatic testbench generator.

Specman Elite automated key aspects of the verification environment. Specifically, it works by generating stimuli into the device, inputs which can be fully random or fully directed. In this way, we can reach specific corner cases in the design without having to force a specific state. We can generate the inputs pre-run, on the fly, or a combination of the two.

Verisity's AHB eVC was also used. An eVC (e Verification Component) is a reusable piece of verification code written in Verisity's e verification language. Specifically, the AHB eVC is a reusable verification environment for ARM's AHB bus. We purchased this code because the AMBA AHB is an industry-standard bus. Essentially, this means that a verification environment for this bus would be very similar no matter what the end design. So rather than spend time creating, and recreating, an environment for this standard interface, we chose to purchase it from Verisity and drop it into the design. Just like an IP design core, this allowed time to be spent on verifying the unique aspects of the design rather than the standard components.

The Specman Elite environment was built around the AHB eVC and layered a macro language on top of the underlying multi-AHB environment. This allowed us to create a virtual AHB environment using a combination of RTL and e masters, and slaves and bus arbitration.

Two complete AHB environments were instantiated using the eVC. This enabled us to attach a master from each environment into an Excalibur system model. The system model consisted of the stripe, external device models, and pseudo PLD models (see Figure 2, p. 24). We used one AHB master in the place of the ARM processor and the other at the PLD bridge interface. By developing specific initialization and co-operation mechanisms between the two masters, we could readily verify the memory areas in truly "realistic" scenarios. By generating random transaction traffic from each master, we ensured that millions of transaction sequence permutations could be directed at each multi-AHB module. By this implication, these complex traffic sequences ensured that the bridges were thoroughly exercised.

The whole Excalibur verification environment thus comprised the AHB eVC, a layer of code to create the environment through multiple instantiations of the eVC and create the various communication mechanisms to allow multiple master operations, and a number of e macros to implement a higher-level language for sequencing directed and random AHB traffic. The actual verification environment comprised around 2000 lines of e, which is much smaller than we expected for a project of this complexity.

Macro language
One of the major objectives for the Excalibur verification environment was the ability for the non-Specman "savvy" engineers to be able to easily use the environment to develop tests. We achieved this through an "assembler-like" language that was built in a layered way using Specman Elite macros on top of the AHB eVC. The flexibility to layer our macro language on top of the e code is a unique feature of the e language and was significant in ensuring that all the engineers could easily be productive in the Specman Elite environment.

The best way of illustrating the benefit of this approach is through an example:

// This is the generator for the AHB1 bus extend AHB1 ahb_master {
// setup registers and generate a sync event
write_reg reg.MMAP_EBI1 value=0x4000_0881;
write_reg reg.MMAP_EBI2 value=0x5000_0881;
write_reg reg.EBI_CR value=0x0008_0048;
// do some bursts to SRAM to check splits
write_read_burst 0x4000_000 check=TRU
size=WORD kind=INCR16;
// let the PLD master go now
write_reg 0x4000_0040 value=0xaaaa_5555
sync_event=TRUE sync_num=1;
multi_burst 0x4000_0000 to 0x4000_0700
num=5100;
};

// This is the generator for the PLD master bridge extend PLD_M ahb_master {
write_reg 0x4000_0800 value=0x1234_5678
trigger=TRUE trigger_num=3
read_reg 0x4000_0800 exp=0x1234_5678
};

Although the "extend" blocks and syntax might seem unfamiliar, most engineers can immediately make sense of the structure and function of this code. The two extend blocks control sequences of bursts to be generated at the two injection points identified in the verification architecture diagram. The instructions within each block loosely resemble assembler type notation and are hence easily understood by non-Specman Elite trained engineers. Each extend block controls the sequence of bursts generated and contain communication mechanisms to allow one master to initialize the register map before allowing the other master to transition out of an idle state. This mechanism was crucial in the development of tests as the two masters must be able to run from completely asynchronous clocks and interact in order to ensure specific bursts happen at or after specific events on the other master.

In fact, a huge number of the Excalibur system-level verification tests are sequences of code similar to the above. The key feature where the macro language differs from what one might call assembly language is in the final command "multi-burst". This simple command allows the user to generate a large number of AHB bursts to a specified memory area. The bursts are generated at random addresses in the address range, of random size and type and contain a write burst followed by an identical read burst at the same address expecting the precise same data written in the first burst. This simple mechanism provides total bus integrity checking across multiple clock domains and to any random access memory area.

Through a constraint mechanism it was a simple matter to direct the traffic to be of say one burst length (in the case, for instance, when we knew a burst length of 16 would highlight a bug) in order to hit specific corner cases. There are a large number of FIFO structures within the Excalibur silicon and creating scenarios where they were full or empty was easy to achieve.

The complete verification suite in the Specman Elite environment comprised more than 60 tests written using these "high-level" language constructs. The longest of these tests was 600 lines and in total, the test base comprised around 14,000 lines of code. This is an extremely small amount of tests given the complexity of the design, and it enabled us to get unparalleled coverage with a minimum number of tests and lines of code.

One of the goals in developing the verification environment was that it be reusable for the gate-level verification, as well as future Excalibur derivatives. The AHB eVC is designed in such a way that re-use for gate-level verification proved to be straightforward. In fact, the environment is already in use for the verification of the next generation of Excalibur devices.

It was also very easy to integrate Specman Elite tests with user developed ARM code tests running from Flash. This allowed considerable "real-world" testing of the arbitration on the AHB2 bus as we could drive in transactions via the PLD master interface whilst code was executing from Flash via the EBI.

Because of the general purpose nature of the Excalibur design, and its verification environment, it would be a simple matter to re-use the environment for any multi-AHB verification exercise. The users of the Excalibur device may well be looking for an environment somewhat similar to that used to develop the actual device. This is something being looked at for the future.

Facing the challenge
Using a new verification methodology can appear daunting as it represents such a critical high-impact part of any SOC development. The Excalibur project demonstrates that when facing a tough verification challenge, teams that take the challenge often find that the risks are in fact manageable and the benefits are significant. By using the approach that we did, we were able to meet all our stringent requirements for the verification of this complex system. The extensibility of the e language, the macro facility and the power of Specman Elite's built-in generator were key elements that enabled this approach to be successful.

There is no doubt that early indications from the first silicon are that the investment in this approach has provided crucial quality benefits in potential early bug identification and fix prior to going to silicon. Within hours of receiving packaged parts in the lab, Altera had the processor booting and executing code. In addition, these features will enable us to reuse the environment that will prove to be a huge benefit in rolling out future Excalibur products -- evolutions of the original EPXA10 design.

Nick Heaton is a principal engineer for Excel Consultants (High Wycombe, U.K.). Ed Flaherty is a senior manager of microprocessor design for Altera Corp.